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ABSTRACT 



A^stem for f acilitating employment searches using ano ny- 
mous communications includes a plurality of par ty 
t erminals , a plurality o£ requestor terminals, and a cent ral 
CQ^fiajjgr. llie system receives and stores employment d ata 
about prospective empioymeni cand idates. Upon receivi ng 
c atena tor candidates of iiiteresi i rom an employer and 
authorizatio n fr om the candidates, ihe cenirai~conir oller 
re leases to the employer the employment data associated 
wTth the candidates. The system also establishes commu ni- 
cations channels between the employer and the candidate s, 
w hile maintaimng their anonymity. 

33 Claims, 12 Drawing Sheets 
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METHOD AND SYSTEM FOR 
FACILITATING AN EMPLOYMENT SEARCH 
INCORPORATING USER-CONTROLLED 
ANONYMOUS COMMUNICATIONS 

BACKGROUND OF THE INVENTION 

Field of the Invention 

Ttie present invention relates to establishing anonymous 
communications between two or more parties. More 
specifically, the invention relates to controlling the release of 
confidential or sensitive information of at least one of the 
parties in establishing anonymous coramimications. 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is related to U.S. patent application Ser. 
No. 08/711,437 entitled "METHOD AND SYSTEM FOR 
FACILITATING WHISTLE-BLOWING INCORPORAT- 
ING USER-CONTROLLED ANONYMOUS 
COMMUNICATIONS'^ now abandoned; appHcation Ser. 
No. 08/708,969 entitled "METHOD AND SYSTEM FOR 
MATCHMAKING INCORPORATING USER- 
CONTROLLED ANONYMOUS COMMUNICATIONS"; 
application Ser. No. 08/708,968 entitled "METHOD AND 
SYSTEM FOR ESTABLISHING AND MAINTAINING 
USER-CONTROLLED ANONYMOUS COMMUNICA- 
TIONS"; and application Ser. No. 08/711,436 entided 
"METHOD AND SYSTEM FOR FACILITATING NEGO- 
TIATIONS INCORPORATING USER-CONTROLLED 
ANONYMOUS COMMUNICATIONS", now abandoned, 
each of which filed on Sep. 6, 1996 and assigned to the 
assignee of the present invention. 

Description of the Related Art 

The need for anonymous communications can be found in 
everyday situations. Police hotlines solicit tips from the 
public to help solve a crime, often- without requiring callers 
to give their names. Cash rewards are often offered for the 
return of missing items with no questions asked. 

One form of anonymity involves "shielded identity/' 
where a trusted agent knows the identity of a masked party, 
but does not reveal that identity to others except under very 
special circumstances. Unless otherwise specified, the term 
"anonymity'* is used throughout this application inter- 
changeably with the notion of shielded identity. 

Shielded identity appears in a wide range of useful and 
commercial functions. A company might run an employment 
advertisement in a newspaper with a blind P.O. box known 
only to the publisher. A grand jury could hear testimony 
from a witness whose identity is known only to the pros- 
ecutor and the judge, but is concealed from the jurors, the 
accused, and opposing counsel. A person could identify a 
criminal suspect from a lineup of people who cannot see 
him. A recruiter could contact potential candidates for a job 
opening without revealing the cUent's name. Witness pro- 
tection programs are designed to shield the true identity of 
witnesses enrolled in the programs. A sexual harassment 
hotline could be set up for victims of sexual harassment to 
call in with their complaints, while promising to protect the 
callers* identities. 

The above examples illustrate the need for anonymity or 
shielded identity due to a fear of exposure. The nee for 
anonymity can also be motivated by a desire for privacy. For 
instance, donors may wish to make an anonymous charitable 



i4,270 

2 

contribution, an adoption agency typically shields the is 
entity of a child's birth mother, a Catholic confessional 
offers anonymous unburdening of the soul, and local phone 
companies maintain millions of unlisted telephone numbers 

5 accessible only by special operators. 

The concepts of anonymity and shielded identity do not 
lend themselves to conventional communication systems. 
While it is possible to send and receive anonymous 
messages, such as a postcard with no return address or a call 

10 placed from a pay phone, it is difficult for parties e gaged in 
multiple commimication episodes to remain anonymous 
from one another. In general conventional communication 
systems are premised upon the notion that communicating 
parties know each other's identity. For the purposes of this 

15 mvention, the term "communications system" refers to any 
system that facilitates an ongoing cycle of messages and 
responses. 

Most current communications systems, whether written or 
oral, do not permit an ongoing, multi-party, shielded identity 
dialogue. For example, letters need an address to be 
delivered, calling someone on the phone requires a phone 
number, and meeting face-to-face provides for visual iden- 
tification. The process involved in most ongoing communi- 
cation systems is simply not conducive to retaining con- 

^ cealed identities. 

Yet, in some cases, concealing identity can actually 
encourage or facilitate communication between unwilling or 
cautious parties. For example, a party negotiating a peace 
treaty with another may be unwilling to reveal his identity 
becaiise, if the negotiations fail, that party might be exposed 
or subjected to potential blackmail. 

One specific example of the need for concealing identities 
is in the employment search process, where the release of the 

35 name of the hiring company (or the position involved) could 
be damaging to the company. The hiring company might be 
concerned about how potential competitors would use the 
knowledge that the company is searching for employees to 
upset customers who are relying on the stability of the 

40 company. Mere speculation that a company is searching for 
a new president could dramatically reduce the price of the 
company's stock. To find potential candidates for the vacant 
position, the company could engage an employment search 
firm to discretely find potential candidates without disclos- 

45 ing to the market, or even potential candidates, the compa- 
ny's identity until the company decides to confide in or hire 
a particular candidate. 

In engaging such employment search firms, however, a 
hiring company entails some risk that the search firm will 

50 prematurely or indiscriminately reveal the company^s iden- 
tity to a potential candidate. Search firms are generally 
compensated based upon the number of successful 
placements, and thus are motivated to make vacant positions 
appear as attractive as possible to potential candidates. In 

55 doing so, search firms could be tempted to reveal enough 
information about the company for potential candidates to 
discover the identity of the company, or, for that matter, the 
firms may reveal the company's identity itself . Accordingly, 
hiring companies cannot be counted upon to maintain effec- 

60 tive control of what information is released to potential 
candidates, and thus are unable to instill any satisfactory 
degree of confidence in their clients about the confidential 
status of their search for job replacements. 

The use of search firms also creates inefficiencies. In 

65 dealing with a search firm, candidates looking for a new job 
may engage in a dialogue with the search firm, asking a 
series of detailed questions about the particular job, com- 
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pany expectations, various qualification criteria, benefits, Pat, No. 5,164,897 discloses an automated method for 

options, perks, and other factors, all w^ithout the candidate selecting personnel matching certain job criteria. Databases 

knowing the name of the hiring company. In response, the storing employee qualifications are searched to identify 

search firm may reveal, from general to specific, information which personnel have qualifications matching search crite- 
about the hiring company. For instance, in response to 5 ria. Such a system, however, does not provide anonymous 

questions, the search firm may successively reveal that the communications between the employer and the employee 

hiring company is a Fortune 500 company, a transportation ^nd does not provide control over the release of information 

company, an airline, headquartered in the Midwest, and, ^^^^^^ ^^^^^ ^^^^^ systems to others. Thus, there is a need 

finally, that it is United Airlines. In return, the candidate may ^ ^^^^ ^^^^ ^jj^^^ exercise control over the 

also authorize the search firm to release information about ^^^^^ information to others and that provides efficient 

Itself For instance, the search firm may disclose that the ^ ^™T«.,«,v,*;r.r, 

candidate is employed at a smaU software company, that he ^o^y^^^^ communication. 

is the head of a software development group of seven SUMMARY OF THE INVENTION 

programmers, then that he is earning $75,000 plus a $20,000 . , . . , ^. 

bonus in his current job, then that he is located in the Accordmgly, the pre ^nt invention is directed to a com- 

Stamford, Conn, area and then finally his identity. munications method and system that obviates problems due 

From the outside, these actions may appear to be a type ^o limitations and disadvantages of the prior art 

of "dance - where each party seeks to learn the necessary A goal of the in vention is to provide a communicaUop 

information to keep the process moving forward. To answer sj^tem incorp orating a central database ot mtomiation sup- 

any difficult questions, the search firm, trusted by both nlied hv one or more of parties and managed by a central 

parties, facilitates an assisted dialogue between the candi- ^^^^r, where all parties to the system can manage 

date and the company. anacojULol the release of anv o_r all information a^t 

By creating this additional layer in the communication themselves or their^jteiti^s, and^here such a ^m 

process, however, the amount of effort and expense incurred all ows lor electronic-based communications betw ^the 
by the hiring party and the candidates increases. Further, ^ pa p^J^a^^ nw - SSity of rovr.alinr th^ idengtj^of 

using such a search firm creates delays in communicating ^unffT pany 

information between the company and the candidates and Another goal of the invention to allow parties to submit 

increases the hkehhood that misunderstandings may occur. criteria for searching a trusted agent's confidential database 

In addition, the success of a search firm to fill a position receive a count of the number of records that satisfy the 
is limited by the number of candidates that the search firm 30 criteria, without reveahng the identities of the parties asso- 

contacts. Search firms may target only certain individuals ^1^^^^ with those records. 

while overlooking many other quahfied candidates who, if A further goal of the invention is to allow a system 

contacted, would have been very interested in considering administrator to send a request for authorization to release 

the available positions. As such, search firms often do not mformation about a party to a searching party, 
reach a large pool of potential candidates. Search firms also 35 Other goals of the invention are to provide a system that 

know that the candidates most qualified for jobs are those encrypts communications between parties to maintain the 

that are currently employed. Recruiters would love to be anonymity of the parties; to authenticate searchable infor- 

able to show these coveted employees even better opportu- mation contained in a central database for release to parties; 

nities. Unfortunately, search firms have no way of identify- to allow one or both parties to receive compensation for 

ing and contacting these prime candidates. Present systems contributing or maintaining information accessible in a 

for recruiting typically rely on the candidate to present database; and to allow one party to apply a customized 

himself to the recruiter — at a substantial risk to the scoring algorithm to information contained about other 

employee. No system currently gives an employee the parties in a database. 

incentive and protection he needs to feel comfortable sub- Still other goals of this invention are to provide a system 
mitting his resume. 45 for a trusted agent to act as an anonymous remailer or 

Another area in which shield identity may be desirable is communicate via e-mail or other electronic means with 

dating. For example, a person could serve as a match-maker specific outside parties requested or identified by one of the 

by setting up two people with whom he is acquainted on a parties to vaUdate information about the parties, 

bhnd date. Before agreeing to go on the date, each acquain- Yet another goal of the invention is to be able to store and 
tance may ask the match-maker questions about the other 50 auftenticate such information that may be provided b y 

person and instruct the match-maker not to reveal his/her outside parties in a central databas e while allowing the 
identity without prior authorization. Once each of the * out^e parties to re tai n^contrQl o v er the rele ase of respective 

acquaintances feels comfortable about the other person, i nformation t o^other pa^f^es. 

he/she may authorize the match-maker to reveal his/her T his invention meets thes e goals by allowing a part y to 
identity and agree to the date. 55 q iaintaLneSctive control over the timing and release of 

Again, however, the use of match-makers suffers from the certain intprmation stored m a database, Including the par- 

same drawbacks as the search firms. There is tittle or no t^'s identity and other relevant data about th e party, to 

control over what information match-makers disclose. For anottier party, itiis con troiiea releas e oTiB entity can_ be 

instance, a match-maker may feel greater loyalty to one of p erformed gradually in a series ot' ste^js where th e pSy 
the acquaintances and willingly divulge the identity of the eo authorize s release ofmore and mo re infc rm ationT Th e inven - 

other acquaintance. Also, using match-makers slows down tion also authenticates information stored in'^e databas e 

the communication process and can result in miscommuni- before rele asing the intormation, thereby improving the 

cation. Finally, the number of people that a match-maker can reliabitity o l the released miormation. Fmally, the invention 

set up is limited by the number of people to whom the estabhshes a communications channerbetween a party and 
match-maker is acquainted. 65 a requestor while not necessarily revealing the identity of the 

Attempts have been made to automate the employment party Jind/or the requestor to each other The controlled 

search process and matchmaking process. For instance, U.S. release of information in the invention allows for new 
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improvements in the quality of the commuaication process FIG. 9 illustrates a detailed flow diagram of a preferred 

when one party to the process would suffer significant costs method for transmitting party and requestor information in 

or be exposed to significant risks if their identity were a communications channel in accordance with this inven- 

released prematurely or indiscriminately. tion. 

According to the pr esent invention, a method and syste m 5 

is dfeciosed tor operatmfi a computer system to tacilitatTa n DETAILED DESCRIPTION OF THE 

exchange of identiti e s be tw een two anonymQBS_narties. T he INVENTION 
rngtSbcrahagy^temSe^perative to receive from a^ fi^gartv 

first data iiicluding an identity of the first party and to recei ve System Structure 

from the first party at least two first-party rules for releasing ^« . 

tK e tirst dat a in E l udinfi a rule for releasing the ide^Htyj^ aid FIG^l illustrates one embodiment of an anonymous 
fl ^t party, i he s ystem and metbodlre further operafive to communication system 100 rirmrdmp to this invention, 
r eceive from a second part y a search request comprising a t System 100 identifies parties haviiig characteristics of inter- 
least one search cri terion; recTive irom die second gS ty est to a requestor, releases certain information about the 
s econd d ata mcluding an identity of the second pa rty; and identified p arties to the requestor with authorization from the 
receive from the sec ond party at least two second-p arty mles parties, releases certain information about the requestor to 
for r6 leas ing the sc g onrl paHy Hatii ( rrlnHing a mlp. jFnr the identified parties with authorization from the requestor, 
releasin g the identity of the second party. and provides a communications channel between the iden- 
' The system and method are further operative to process tified parties and the requestor while maintaining their 
said search request to determine if the first data satisfies the anonymity. For example, system 100 can be used to allow an 
search criterion and if so, then exchanging the first and 20 euip]oyer (the requestor) to communicate with prospective 
second data, except the identities of the first and second candidates (the parties) whose background satisfies employ- 
parties, between the first and second parties in accordance me^t criteria provided by the employer without revealing the 
with the first-party and second-party mles. The system and identity of the employer or the identities of the candidates, 
method are further operative to transmit the identity of the ^ specific example, a software company may want to hire 
first party to the second party after the exchanging step, upon 25 ^ programmer with 5+ years experience in writing C++, who 
satisfying the first-party rule for releasing tiie identity of the ^ willing to live in Seattle, who will work 12-14 hour days 
first party, and after the exchanging step, upon satisfying the g days a week, who will work for between $100,000 to 
second-party rule for releasing the identity of the second $150,000 in salary plus bonuses, and who wants the oppor- 
party, transmitting the identity of the second party to the first [^^[i^y work for a startup with stock options in a publicly - 
party. traded company that could effectively double his salary. 
BRIEF DESCRIPTION OF THE DRAWINGS S ystem 100 could identify a dozen candidates firom resu mes 

stored in a database, release information about these can di- 

The accompanying drawmgs provide a further under- j^te s only as authorized to the company, an d deliver"^es - 

standing of the mveoUon and are mcorporated m md con- s^s between Ibe" " mpany ana candiaate r^ithout th e 

stitute a part of this specification. The drawings lUustrate 35 company eve r knowmg ihe candidates identities. Althoug h 

preferred embodiments of the mvention, and, together with t he invention can be used in conne ction with ^ er 

the description, serve to explain the prmciples of the inven- ap plications, for the purpose ot illustration, the^ mpj ^ent 

se arch example is used tfiroughout the specilication7 

In the drawmgs: System 100 includes a public switched phone network 

HG. 1 Illustrates one embodiment of the present mven- 40 ^ ^^^^^^ controller 200, party terminals 300, and 

requestor terminals 400. Central controller 200, party ter- 

FIG. 2A Ulustrates a block diagram of the central con- ^^^^ ^qq^ requestor terminal 400 preferably connect 

troUer of the system in accordance with the embodiment in networic 110 through respective two-way communication 

FIG. 1; hriks. Parties (e.g., candidates) access system 100 through 

HG. 2B illustrates the contents of a party data database respective party terminals 300, and a requestor (e.g., an 

and a requestor data database in accordance with the employer) accesses system 100 through requestor terminal 

embodiment in FIG. 1; 400. The flow of data from terminals 300 and 400 is 

FIG. 2C illustrates the contents of a verification database preferably limited and controlled by central controller 200. 

and an account database in accordance with the embodiment ^^^^^ control of central controller 200, public 

in FIG. 1; switched telephone network 110 routes data to and from 

HG. 3 illustrates a block diagram of a party terminal in central controller 200, party terminals 300, and requestor 

accordance with the embodiment in FIG. 1; terminal 400. In a preferred embodiment, network 110 

FIG. 4 illustrates a block diagram of a requestor terminal comprises a commercially-implemented network of 

in accordance with the embodiment in FIG. 1; computer-controlled telephone switches operated by, for 

HG. 5 illustrates a flow diagram of a preferred method for example, a telephone company. Network 110 may also 

establishing anonymous communications in accordance include communication networks other than a public 

with this invention; switched telephone network, such as a wireless network, a 

FIGS. 6A-6B illustrate a flow diagram of a preferred paging network, or the Internet, 

method for searching for and releasing party data m accor- so Central controller 200 controls the flow of data to an d 

dance with this invention; froffl ^jparty terminals 300 and requestor ter minal 40 0. 

HG. 7 illustrates a flow diagram of a preferred method for Preferably, central controller 20 0 stores and auth enticates 

verifying the authenticity and accuracy of party data in t he authorship Of "pany data" and ''requestor data ^"rec eived 

accordance with this invention; from part y terminals 30U and requ estor termmal 400, resp ec- 

FIG. 8 illustrates a flow diagram of a preferred method for 65 d vely. 'Tarty data" comprises data about or corresponai ng to 

opening a communications channel between a party and a a respective party. "Requestor data^' comprisesO ataaGbutor 

requestor in accordance with this invention; and c(^esponding to the requestor. In the employment search 
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example, p arty data would include information that may be data database 255 and requestor data database 260, and FIG. 

o Tinterest toan employer about respective candidates, su ch 2C illustrates record layouts for verification database 270 

as a,candidate's ident ity, the candidate's address, the c an- and account database 275. Each record layout preferably 

di date's vital statistics, the candidate's work experience^ t he comprises a two-dimensional array of information with one 

cand idate's educational background, and the candidate 's 5 column for "Field Name'' and another column for "Field 

interestSj^^- Characteristic/' The rows correspond to respective fields. 

In one embodiment used with an employment system, Xbe "authorization profile" field contained in each of the 

each party fills out an electronic form that gets converted patty data a nd requestor data dat abases preieraPiy compri ses 

into an HTML format. This presents the party's employment a list of rules foi^rele_asing ^ party or requesto r _data. For 

history as a "hyper- resume." When released to a requestor, 1° e xample, the rules could simply include a fist 6^ companie s 

this resume allows the requestor to get more information to' ^bich party dat^ not to be released, or include cE ar- 

about certain areas of a party's history. The hyper-links can act eristics of certain companies to which party data can be 

point to additional text, QuickTime video, JPG photos or relea^d, such as mmpanies that are in the Fortune SOO^d 

audio cUps, allowing for a rich presentation of information hav.g_&£Qckr option plane. 

about the party. Requestor data would include information 15 Verification database 270 preferably includes cross- 
about the employer, such as the employer's identity, the referencing fields (not shown) to party data database 255 and 
number of its employees, the locations of its offices, the requestor data database 260. This allows indexing by veri- 
industry in which the employer operates, the positions fied information as well as other types of searches, 
available and their job descriptions, fiscal information about ^.p^ 205 executes program instructions stored in RAM 
the employer, and the history of the employer. The requestor 20 ^^^^ ^^^^ ^^^^^^^ ^^^^ ^50 to perform 
data is collected and stored using similar techniques to those various functions described in connection with FIGS. 5-9. 
ouUined above for an employee's employment history. ^ preferred embodiment, CPU 205 is programmed to 

Ij Q__addition, central controller 200 controls the release of maintain data, including party data and requestor data, in 
re questor data and party data that the requestor and respe c- ^ storage device 250. CPU 205 receives party data and 
ti ye par^fes. respectively, have authorized for release. Cen- requestor data from network 110 through network interface 
tral controller 200 also establis hes a cnmmiinicatinns chan- 245 and stores the received parly data and requestor data in 
hel between party terminals 300 and requestor terminal 400, databases 255 and 260, respectively. CPU 205 is also 
while maintaining the anonymity of the parties using party programmed to receive and store information in party data- 
terminals 300 and the requestor using requestor terminal base 255 and requestor database 260 indicating which of the 
400. The structure of controller 200 is described in greater party data and requestor data respective parties and request- 
detail belo\v ip conn rr^^^" ^^^^ ^Q, '^^ ors have authorized for release. Upon receipt of a request for 

Party terminal 300 provides a party with an interface to authentication, CPU 205 transmits a veri&calion request to 
system 100. Preferably, party terminal 300 allows a party to a verification authority to authenticate the origin, authorship, 
enter party data and transmits it to central controller 200 via and integrity of the party data and requestor data stored in 
network 110, Party terminal 300 also allows a party to databases 255 and 260, respectively, and maintains a record 
indicate which of the entered party data system 100 is of the verification request in database 270. 
authorized to release to a requestor, view requestor data, and ^py 205 is also preferably programmed to search data- 
communicate anonymously with the requestor at requestor bases 255 and 260 and transmit information in response to 
terminal 400. The structure of party terminal 300 is ^ the search. CPU 205 receives a search request containing 
described in greater detail in connection with FIG. 3. certain criteria and searches the databases of storage device 

Requestor terminal 400 provides a requestor with an 250 to find matches. Based upon the search, CPU 205 

interface to system 100. In a preferred embodiment, releases certain information to the requestor and the parties, 

requestor terminal 400 allows a requestor to enter requestor Also, CPU 205 preferably assigns pseudonyms to each party 

data and transmits the requestor data to central controller 45 and requestor, and stores the pseudonyms in databases 255 

200 via network 110. Requestor terminal 400 also allows a and 260, respectively. The pseudonyms can include coded 

requestor to enter search criteria about parties of interest, to identifiers, web page addresses, bulletin board addresses, 

indicate which of the entered requestor data system 100 is pager numbers, telephone numbers, e-mail addresses, voice 

authorized to release to a particular party, view party data, mail addresses, facsimile telephone numbers, and postal 

and communicate with parties at party terminals 300. The mail addresses. 

structure of requestor terminal 400 is described in greater (-py 205 receives search criteria pertaining to parties of 

detail in connection with FIG. 4. interest to the requestor and searches database 255 to 

FIG. 2A illustrates a block diagram of central controller identify parties whose party data satisfies the search criteria. 

200. As shown in FIG. 2A, central controller 200 includes There are a number of search techniques that can be used 

CPU 205, cryptographic processor 210, RAM 215, ROM ss including keyword, fiizzy logic, and natural language search 

220, network interface 245, and data storage device 250. tools. For example, an employer could search for candidates 

Data storage device 250 includes a plurality of databases, with the following criteria: "two years of patent writing 

including party data database 255, requestor data database experience and lives in New England." CPU 205 compares 

260, verification database 270, and account database 275, as the criteria against each party registered with the system 

well as program instructions (not shown) for CPU 205. CPU 50 using one or more search algorithms and transmits to the 

205 is connected to each of the elements of central controller requestor the number of parties identified. If CPU 205 

200. receives a request for party data corresponding to the 

The databases in data storage device 250 are preferably identified parties, CPU 205 transmits to requestor terminal 

implemented as standard relational databases capable of 400 the party data that the identified parties previously 

supporting searching and storing multimedia information 65 authorized for release along with respective pseudonyms, 

such as text, video, QuickTime movies, photographs, and CPU 205 can also transmit queries to party terminals 300 

audio. FIG. 2B illustrates exemplary record layouts for party inquiring whether respective parties authorize the release of 
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additional party data. If CPU 205 receives a request for 
requestor data from a party, CPU 205 transmits to the 
appropriate party terminal 300 the request data that the 
requestor previously authorized for release, along with a 
pseudonym corresponding to the requestor. 5 

CPU 205 is preferably also programmed to provide an 
anonymous communications charmel between party termi- 
nals 300 and requestor terminal 400. CPU 205 receives a 
request for an anonymous commimications channel along 
with a pseudonym of a party and a requestor. In one lO 
embodiment, CPU 205 establishes either a real-time or 
non- real-time communications channel between the party 
and the requestor corresponding to the received pseud- 
onyms. For example, CPU 205 could transmit control sig- 
nals to configure network 110 to provide a direct telephone 15 
connection between the party and the requestor at their 
respective terminals 300 and 400, thereby establishing a 
real-time communications channel. In another example, 
CPU 205 could receive and store electronic mail messages 
in electronic mailboxes assigned to the party and the 20 
requestor for their retrieval, thereby establishing a non-real- 
time communications channel. 

CPU 205 preferably comprises a conventional high-speed 
processor capable of executing program instructions to 
perform the functions described herein. Although central 
controller 200 is described as being implemented with a 
single CPU 205, in alternative embodiments, central con- 
troller 200 could be implemented with a plurality of pro- 
cessors operating in parallel or in series. 

RAM 215 and ROM 220 preferably comprise standard 
commercially -available integrated circuit chips. Data stor- 
age device 250 preferably comprises static memory capable 
of storing large volumes of data, such as one or more floppy 
disks, hard disks, CDS, or magnetic tapes. 

Network interface 245 connects CPU 205 to network 110. 
Interface 245 receives data streams from CPU 205 and 
network 110 formatted according to respective communica- 
tion protocols. Interface 245 reformats the data streams 
appropriately and relays the data streams to network 110 and 
CPU 205, respectively. Interface 245 preferably accommo- 
dates several different communication protocols. 

Cryptographic processor 210 is programmed to encrypt, 
decrypt, and authenticate the stored data in each of the 
databases described above. Cryptographic processor 210 
encrypts and decrypts data received by and transmitted from 
CPU 205. In a prefened embodiment, all party data and, 
requestor data are encrypted before being transmitted onto 
Detwork 110. Also, processor 210 encrypts the data before 
CPU 205 transmits such data via network 110. Any 
encrypted data received by CPU 205 is decrypted by pro- 
cessor 210. The cryptographic protocols used by crypto- 
graphic processor 210 are described below in the section 
entitled "Cryptographic Protocols." 

FIG. 3 illustrates a block diagram of party terminal 300, 
according to one embodiment of the invention. Party termi- 
nal 300 includes CPU 305, which is connected to RAM 310, 
ROM 315, video driver 325, cryptographic processor 335, 
communication port 340, input device 345, and data storage 
device 360. Video monitor 330 is connected to video driver 
325, and modem 350 is connected to communication port 
340 and public switched phone network 110. 

CPU 305 executes program instructions stored in RAM 
310, ROM 315, and information storage 370 to carry out 
various functions associated with party terminal 300, In a 
prefened embodiment, CPU 305 is programmed to receive 
data from input device 345, receive data from coramunica- 
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tion port 340, output queries and received data to video 
driver 325 for display on video monitor 330, and output data 
to communication port 340 for transmission by modem 350. 
CPU 305 preferably transmits the data to cryptographic 
processor 335 for encryption before outpulting data to 
communication port 340 for transmission to network HO. 
When CPU 305 receives encrypted data, CPU 305 transmits 
the encrypted data to cryptographic processor 335 for 
decryption. 

CPU 305 preferably comprises a high-speed processor 
capable of performing the functions described herein. RAM 
310 and ROM 315 comprise standard commercially- 
available integrated circuit chips. Information storage 370 
comprises static memory capable of storing large volumes of 
data, such as one or more of floppy disks, hard disks, CDs, 
or magnetic tapes. Information storage 370 stores program 
instructions and received data. 

Video driver 325 relays received video and text data from 
CPU 305 to video monitor 330 for display. Video monitor 
330 is preferably a high resolution video monitor capable of 
displaying both text and graphics. Cryptographic processor 
335 encrypts and decrypts data in accordance with conven- 
tional encryption/decryption techniques and is preferably 
capable of decrypting code encrypted by cryptographic 
25 processor 210. Communication port 340 relays data between 
CPU 305 and modem 350 in accordance with conventioual 
techniques. Modem 350 preferably comprises a high-speed 
data transmitter and receiver. Input device 345 comprises 
any data entry device for allowing a party to enter data, such 
30 as a keyboard, a mouse, a video camera, or a microphone. 
The operation of party terminal 300 is described in greater 
detail in connection with FIGS. 5-9, 

FIG. 4 illustrates a block diagram of requestor termiaal 
400 according to the invention. Terminal 400 in FIG. 4 
35 includes CPU 405, which is connected to RAM 410, ROM 
415, video driver 425, cryptographic processor 435, com- 
munication port 440, input device 445, and data storage 
device 460. Video monitor 430 is connected to video driver 
425, and modem 450 is connected to communication port 
40 440 and public switched telephone network 110, Terminals 
300 and 400 are shown in FIGS. 3 and 4 to be structurally 
similar, though different reference numerals are used. As 
such, a more detailed description of terminal 400 can be 
obtained by referring to the above description of terminal 
45 300. In a preferred embodiment, however, terminals 300 are 
used by parties, whereas terminal 400 is used by a requestor. 

Cryptographic Protocols | 
j\s described above, syste m 100 encrypts data before 
5Q transferring such data betw een^ sysiem users (mcLuding b oth 
p arties and requestors) ana central control|feiL200 , thereby 
p rovi^ jjig. vaj^ ^jsj e yels of s ecurit;^ a nd pnyacv p rotediQn . 
As used^rotighout^this section, the term "users" refers to 
both parties and requestors. A book entitled Applied Cryp- 
55 tography: Protocols, Algorithms, And Source Code In C by 
Bruce Schneier (2d Ed, John Wiley & Sons, Inc., 1996) 
describes in detail numerous cryptographic protocols that 
can be used. 

These protocols can be understood from the following 
60 basic overview. 

The following notation is used throughout the description 
of CTyptographic protocols: 

PKE^: refers to the public encryption key of user A. This can 
be an RSA public key or a key for some other public key 
65 encryption scheme. 

SKE^: refers to the secret decryption key corresponding to 
encryption key PKE^. 
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PRS^: refers to the public component of user A's signature 
key. This can be a DSS key or a key for some other public 
key signature scheme. It can also be the same key as 
PKE^ in public key systems like RSA. 

SKS^: refers to the private signature key corresponding to 5 
PKS^. It can also be the same key as SKE^ in public key 
systems like RSA. 

^rKE(M)' refers to the encryption of the plain text message 
M with the public encryption key PKE. 

D^ji^(C): refers to the decryption of the cipher-text message 
C with the secret decryption key SKE. 

E^M): refers to the encryption of message M with a 
symmetric encryption algorithm and key K. It is apparent 
from the context whether the protocol uses pubHc key or 
symmetric key encryption. ^5 

Dj^C): refers to the decryption of the cipher-text message C 
with a symmetric encryption algorithm and key K. 

Sjuts(M): refers to signature of message M with secret 
signature key SKS. 

H(M): refers to the hash of the message M with a crypto- 
graphic hash function like MD5 or SHA. 

A,B: refers to the concatenation of A and B. This is com- 
monly used when describing messages. 
Public key encryption systems are usually several orders 

of magnitude slower than private (symmetric) key encryp- 25 

tion systems. As a result, central controller 200 preferably 

uses the foUowing protocol or the like to encrypt messages. 

Suppose that Alice wants to encrypt a message M so that 

only Bob can read it. 

1. Alice obtains Bob's public encryption key, PKE^, gener- 3Q 
ates a random symmetric encryption key K, and encrypts 

it with Bob^s public key. 

2. Alice encrypts the message M with the key K using a 
symmetric encryption algorithm, like Triple-DES or 
IDEA, and sends 35 
Mo-Ep^K),C 

where C=Ej^. 

3. Bob decrypts the key K using his private decryption key 
K=D^E^^K)) 

and uses the key to decrypt the message 40 
M=D^C)=D^^) 

The bulk of the encryption is done using the symmetric 
encryption algorithm, which is orders of magnitude faster 
than the public key encryption algorithm. When a user 
encrypts a message to central controller 200 using central 45 
controller 200's public key, it is assumed that the user and 
central controller 200 carry out the above protocol. 

Typical signature schemes (e.g. RSA or DSS) use a key 
pair for creating signatures and verifying them. One part of 
the pair, the private part, is used for generating signatures. 50 
The transformation for generating a signature is defined in 
such a way that only someone who knows the private part of 
the key pair can generate a signature. Hence, only the owner 
of the key pair can generate signatures. 

The other part of the pair, the public part, is used to verify 55 
signatures. Anyone, including the owner of the key pair, can 
use the public component to verify that a signature is valid. 
However, it is computationally infeasible to use the public 
component to forge a signature. 

One example of such a signature scheme is the RSA 60 
public-key encryption system. In such a system, each user 
has a public key consisting of a modulus n and an exponent 
e, where n is a product of two secret primes p and q. The 
private component is an exponent d such that ed=l (mod 
(p-l)(q-l)). 65 

To sign a message M with an RSA key pair, the user 
computes 
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SoM'' (mod n). 
where the result S is the signature. In order to verify the 
signature, a user simply computes 

S''-M'^''«M (mod n). 
The signature verifies correctly if the result of computing S* 
(mod n) is the message that the signature is for, i.e. S'-M 
(mod n). Thus, a user must know d in order to generate a 
signature. 

Public key signature schemes, however, are slow and a 
user can only sign messages that are smaller than n (when 
encoded in the ring Z/nZ). One solution is to hash the 
message M with a cryptographic hashing scheme (e.g. MD5 
or SHA), and then sign the hash. The resulting hash is 
usually much smaller than the message and hence easier to 
sign. 

In addition, generating two messages with the same hash 
is computationally infeasible, so it is extremely difficult to 
generate two messages which will have the same signature. 
Therefore, the foUowing protocol is an RSA-hke signature 
protocol which will preferably be used whenever a user or 
central controller 200 needs to sign and verify messages and 
will be known as SsksO^' 

1. Alice generates a message M which she wishes to sign. 

2. Alice computes h=H(M), the one-way hash of M with a 
predetermined hashing algorithm. 

3. Alice computes 
S=h'' (mod n) 

which is her signature. Hence, 
S5a:^(M)-(H(M))^^ (mod n). 

The following protocol can be used by any user to verify 
Alice ^s signature: 

1 . Bob receives a message M and corresponding signature 
S, which he wants to verify. He believes that Alice 
generated the signature. 

2. Bob computes M*=Spj^ (modn) where n is Alice's 
public modulus (it is specified as part of PKS^). 

3. Bob verifies that M=M'. If they match, then Alice's 
signature verifies successfully. Otherwise the verifica- 
tion fails. 

Most of the protocols described require public encryption 
keys or private signature keys (or both). Each user commu- 
nicating with central controller 200 should receive encrypted 
messages from central controller 200 and sign messages that 
they send to central controller 200. Hence, each user in the 
system requires a public/private encryption key pair and a 
pubUc/private signature key pair. As noted above, these pairs 
could be the same pair in systems like RSA. 

Generating a key pair, either signature or encryption, 
depends heavily upon the intended algorithm. A brief 
example for generating RSA encryption (and signature) keys 
is shown below. 

1. Central controller 200 determines the size for the public 
key. Typically, a 7 68 -bit key is the recommended 
minimum, but 1024-bits provide a better minimum. 

2. Central controller 200 generates two primes p and q such 
that p>sqrt(pq)>q, and p and q are not close together (i.e. 
they are both roughly sqrt(n) in size, but different in size 
by two or three bits). 

3. Central controller 200 computes n=pq. This is the public 
modulus. 

4. Central controller 200 chooses a pubUc exponent c. 
Common choices are 3, 17, and 65537 (2^*+l). 

5. Central controller 200 computes the private exponent d by 
finding d such that 

ed=l (mod (p-1) (q-1)). 

Central controller 200 can do this using the extended 
Euclidean Algorithm. 
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6. Central controller 200 publishes n and e as the public key. 1 . Alice obtains a signature key pair. 

e is the public exponent which people use to encrypt 2. Alice generates a key certificate for her public signature 

messages to the public key user (a party, requestor or key, sends a copy of the certificate and the public key to 

central controller 200) or to verify the signature (if the central controller 200, and asks central controller 200 to 

pair is the signature pair). The secret exponent, d, is what 5 sign the certificate. 

is used to decrypt messages sent to the user or to generate 3. Central controller 200 sends Alice a copy of the signed 

signatures. certificate. 

The primes that central controller 200 chooses are pref- 4. Alice obtains an encryption key pair, 

erably chosen at random. If an attacker can determined and 5. Alice generates a key certificate for her public encryption 

q, then the attacker can also determine d. Several tests exist key and signs it with her private signature key. 

for determining whether a randomly chosen number m is Alice sends a copy of her public encryption key, along 

prime or not. Typically one chooses a random number m and ^ ^opy of the signed key certificate, to central 

then uses primahty tests to determine the first prime greater controller 200. 

than or equal to m. p^^j. carrying out this protocol, Alice has a signed 

When encrypting a message to be transmitted or verifying signature key and a signed encryption key. Furthermore, any 

a signature, there needs to be a way 01 ventymg the , -u^ j *j ^ai* 

^.'.,.1 ^ ■.•1. user who wishes to send an encrypted message to Alice or 

appropriate public key. One common way is to implement a , . • ^1 li- 1 

hierarchical certification system in which each valid public Y^^^y signature can obtam the pubhc key component 

keyhasacorrespondingkeycertificate. The key certificate trom central controUer 2UU , . 

is signed by another tiser^s private signature key higher up . ^or most of the protocols descnbed used m the invention 

in the key hierarchy. At the top of the hierarchy is the private 20 is assumed that central controller 200 stores signatures and 

signature key of the certificate authority, whom everyone ^he pubHc components for all signature keys used m the 

automatically trusts. In this case, the certificate authority system. In addition, it is assumed that each user has a copy 

would be central controller 200. public components of both of the central controller 

The puq)ose of a certificate is to bind together in some 200's signature keys. Most commuoication in system 100 

authenticated way a public key, and a set of statements about 25 occurs between parties and central controller 200 and 

this public key. The most important statement made is between requestors and central controller 200. Where a 

usuaUy who owns the public key. Other potentially impor- requestor and a party communicate directly, each obtains 

tant statements might deal with what the key is and is not ^^P^^^ of the other user's pubhc signature and encryption 

authorized to do, and when the key expires. ^eys from central controller 200. 

The best-known standard for key certificates is X.509 . 30 System 100 may be prone to attempted mfiltration, or 

More detailed information on the construction of X.509 "attacks,^' if the requestor and central controller 200 do not 

certificates can be found in GCITT, Dract Recommendation ^^e an interlock protocol. Schneier et al, "Automatic Event- 

X.509, "The Directory-Authentication Framework/' Con- Stream Notanzation Usmg Digital Signatures," in Advances 

sultation Committee, International Telephone and ^'^ Cryptology, Proceedings of the Cambridge Protocols 

Telegraph, International Telecommunications Union, 35 ^OT-fo/io;? 96, Sprmger-Verlag, 1996. The mterlock protocol 

Geneva, 1989 or RSA Laboratories, "PKCS #6: Extended- "^^^^s^' signatures generated by both users of a protocol 

Certificate Syntax Standard," Version 1.5, November 1993. ^o a particular mstance of the protocol. This is accomplished 

In a preferred embodiment of the invention, central con- ^^vmg each user sign a packet which the other user 

troller 200 has at least one signature key pair for which randomly generates. This causes the protocol to be non- 

everyone using the system knows the pubUc signature key 40 deterministic and hence the signatures from one instance do 

In one embodiment of the invention, central controller 200 ^PPly another. The interlock protocol is described 

will use two signature key pairs: one key pair for signing key ^friefiy below. Suppose that a party wishes to send a message 

certificates and one key pair for use in the rest of the ^ ^^°tral controller 200: 

protocols described. Central controller 200 keeps the cer- 1- P^^ty generates a random number Rq and sends 

tificate authority signature pair under lock and key except 45 Mo=^^o> ^^^^(Ro) to Central controller 200. 

for when a key certificate needs to be signed. On the other 2. Central controller 200 verifies the party's signature, 

hand, the other signature key pair is available at all times. Central controller 200 then generates a random number 

Each time a new user (a party or requestor) registers with and sends 

central controller 200, the certificate authority signature key M^-R^, S^^^^(H(Mq),R^ 

is used by central controller 200 to sign a unique signature 50 to the party. 

keypairfor the user. This needs to be done before a user uses 3. The party verifies central controller 200's signature, 

their signature key pair for the first time. In one embodiment Central controller 200 then sends 

of the invention, central controller 200 generates a signature M2«C,S^j^(H(Mi),C) 

key pair and signed key certificate for the user. In an to central controller 200. 

alternate embodiment, the user creates his own key pairs, ss The party and central controller 200 both sign packets 

Once a user involved in the system has a signed key using values which cannot be known before the protocol 

certificate for his public signature key, he can then use that starts. Central controller 200 cannot predict R^, so it cannot 

signature key to sign a key certificate for his public encryp- predict what Mq will look like. Similarly, the party cannot 

tion key. Central controller 200, acting as the certificate predict R^ so he cannot predict what Mj will look like, 

authority, can also sign the key certificates for encryption so Hence, each of them must see the packets before they 

keys. Tliis has the advantage of reducing the number of generate the signatures which means that anyone trying to 

signature verifications. In an embodiment of the present impersonate the party must have the capability of generating 

invention, the same method for generating signature key signatures on his behalf This effectively thwarts a replay 

pairs is used for generating encryption key pairs. attack, which can be used to prevent an attacker from 

A user follows the following basic protocol when regis- 65 gaining, informadoh as demonstrates next, 

tering with central controller 200. Suppose that Alice is such Suppose an attacker Eve observes a party sending some 

a user: encrypted packets to central controller 200. Although Eve 
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does not know what the packets contain, she might be able 
to determine that they contain a resume. If a period of time 
passes in which the party and central controller 200 do not 
commxmicate and then central controller 200 sends the party 
an encrypted message, Eve's confidence that the party sent 
a resume should increase. Now, if Eve were to send the same 
encrypted message to central controller 200 that the party 
originally sent, eventually central controller 200 will send 
another encrypted message to the party. The attack that Eve 
(acting as a requestor) can mount is that she could submit 
one or more legitimate search requests to central controller 
200 and wait for the results. By paying attention to how the 
size of the response to the request varies, Eve can deduce 
some information about the party's data. This sort of attack 
violates the party's privacy. By using the interlock protocol, 
Eve cannot replay the party's packets to central controller 
200 because she won't be able to complete the interlock 
protocol. 

System Operation 

The operation of system 100 is now described in connec- 
tion with the flow diagrams shown in FIGS. 5,6,7,8 and 9. 
FIG. 5 illustrates a flow diagram of a method for providing 
anonymous communication in accordance with one embodi- 
ment of the invention. 

As shown in FIG. 5, central controller 200 receives 
encrypted party data and encrypted requestor data (step 
500). Such encrypted party data and requestor data prefer- 
ably originates from party terminals 300 and requestor 
terminal 400, respectively. In one embodiment, party termi- 
nals 300 prompt respective parties to enter party data by 
displaying requests for information on video monitor 330. 
For instance, in the employment search example, video 
monitor 330 would request information that may be of 
interest to an employer, such as the candidate's identity, the 
candidate's address, the candidate's vital statistics, the can- 
didate's work experience, the candidate's educational 
background, and the candidate's interests. The party would 
enter party data using input device 345. Cryptographic 
processor 335 would encrypt the entered party data and 
modem 350 would transmit the encrypted party data to 
central controller 200 via network 110. 

Requestor terminal 40O preferably operates in a similar 
manner to prompt a requestor for requestor data, receive and 
encrypt the requestor data, and transmit encrypted requestor 
data to central controller 200. Central controller 200 also 
assigns a pseudonym to each party and requestor whose 
party data and requestor data is stored in databases 255 and 
260, respectively. 

After receiving the encrypted party data and requestor 
data, cryptographic processor 210 of central controller 200 
decrypts the received data (step 500). CPU 205 of central 
controUcr 200 stores the decrypted data in databases 255 and 
260, respectively (step 500). 

Central controller 200 receives a search request to identify 
those parties whose party data satisfies certain criteria (step 
510). In a prefened embodiment, the search request origi- 
nates from requestor terminal 400, where a requestor entered 
the search request. Before requestor terminal 400 transmits 
the search request, cryptographic processor 435 of terminal 
400 preferably encrypts the search request. Cryptographic 
processor 210 decrypts the encrypted search request upon 
receipt at central controller 200. Central controller 200 then 
searches party data database 255 and, in response to the 
search, transmits certain information to requestor terminal 
400 and party terminal 300 (step 510). 
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FIGS, 6A and 6B illustrate a flow diagram showing step 
510 in more detail. First, central controller 200 receives 
search criteria from requestor terminal 400 (step 600). This 
search criteria may include, for example, certain employ- 
5 ment quaUfications or educational background that an 
employer is interested in. 

In response, central controUer 200 searches database 255 
for party data satisfying the search criteria (step 610). 
Controller 200 then transmits to requestor terminal 400 the 
10 results of the search, e.g., number of parties that it found to 
have party data satisfying the criteria (step 620). 
Alternatively, the number of parties would be transmitted to 
requestor terminal 400 along with pseudonyms for each of 
those parlies. 

Depending on the number of parties found, the requestor 
may refine or modify the search criteria. If the requestor 
chooses to modify the search criteria, the requestor enters 
the new search criteria into requestor terminal 400, which 
transmits the search criteria to central controller 200 (step 
630), and steps 610 and 620 are repeated. 

Otherwise, central controller 200 determines whether the 
requestor requests party data about those parties found as a 
result of the search (step 640). Central controUer 200 does 
not transmit any further data to the requestor at requestor 

^ terminal 400 and the transmission ends (step 645). 

If the requestor chooses to request party data (step 640), 
the requestor enters the party data request into requestor 
terminal 400, which transmits the request to central control- 
ler 200. Central controller 200 transmits an authorization 
request to party terminals 400 for authorization to release 
respective parties' party data (step 650). 

The party receiving the request for authorization can 
indicate whether to authorize central controller 200 to 

35 release some or aU of its party data by entering one of three 
responses into party terminal 300 (step 660). The responses 
are sent to central controller 200. If central controller 200 
receives a response that indicates that the party does not 
authorize release of any party data, central controller 200 

4Q does not provide any party data to requestor terminal 400, 
and the transaction ends (step 661). If, on the other hand, 
central controller 200 receives a response that indicates that 
the party authorizes release of some or all of its party data, 
central controller 200 transmits that party data to requestor 

45 terminal 400 for the requestor (step 662). 

Central controller 200 could also receive a response 
asking for data about the requestor before authorizing 
release of its party data (step 663). If so, central controller 
200 transmits a query to the requestor at requestor terminal 

50 400 asking for authorization to release requestor data to the 
party (step 670). If requestor does not authorize release of 
any requestor data to the party (step 680), central controller 
200 does not release any requestor data to the party and the 
transaction ends (step 685). If the requestor does authorize 

55 release of some or all of the requestor data to the party (step 
680), central controller 200 transmits the authorized 
requestor data to the party (step 690). Central controller 200 
then awaits the party's response to see whether centra] 
controller 200 is authorized to release party data. 

60 To ensure the parties' authorization to release their party 
data is valid, permission certificates can be used in an 
alternate embodiment of the present invention. For example, 
in an employment system embodiment, parties who use the 
system may not want anyone to know they are hunting for 

65 a job. Candidates may not want any of the people they work 
with to know. As a resiilt, the party would like explicit 
control over who sees their resume. Therefore, whenever 
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central controller 200 gets a request for a release of party 
data, central controller 200 needs to obtain explicit permis- 
sion from the party to send the party's data to the requestor. 
When a party decides to release his party data, he can be sure 
his data will be released only to the requestor making the 
request. The following is a preferred protocol for a party to 
issue a permission certificate: 

1 . A requestor "A" submits a request to release party data J 
and to central controller 200 in order to find out more 
about the party. 

2. Central controller 200 assigns a unique transaction ID, T, 
to the request and creates a modified request J'=(J,T). The 
transaction ID, T, helps ensure that each job description 
(and hence permission certificate) is unique. 

3. Central controller encrypts J' using the party's public 
encryption key and sends the encrypted message to the 
party. Central controller sends 

to the party. The party's public key is included as part of 
the information that central controller 200 signs so a third 
party cannot forward a copy of a job description they 
received from central controller 200 to another party. 

4. The party decrypts the message to retrieve J', verifies 
central controller 200's signature, reads the request, and 
decides if he wants to release his party data. If he doesn't, 
then he stops the protocol here. 

5. The parly generates a message M containing the following 
information: 

A pre-defined string which states that he gives his per- 
mission to release his party data to the requestor. 

A hash of the request H(J'). Note, this is unique to this 
permission certificate since the transaction ID is unique 
to the job description. 

A string which states the details about how he wants her 
party data released, whether or not he wishes to remain 
anonymous, etc. 

6. The party signs the message, encrypts it using central 
controller 200's public encryption key and sends it to 
central controller 200. Hence, she sends 

to central controller 200. 

7. Central controller 200 decrypts the message to retrieve M, 
verifies the party's signature, and transmits the party's 
data to the requestor. 

Because the party signs the message that central controller 
200 sent him in the first step, his signature will only work for 
the job description that central controller 200 sent him. 
Hence, central controller 200 cannot use the permission 
certificate for a different job description. This assumes, of 
course, that the request to release party data contains infor- 
mation imique to that request, such as a transaction ID 
number. Central controller 200 embeds the transaction ID in 
the request to release party data message. 

In an alternative embodiment, central controller 200 could 
assign a different transaction ID to each request and party. 
Hence, two different parties cannot easily check that they are 
getting the same request by comparing transaction IDs. 

The same protocol can be used in any other situation 
which also requires a permission certificate. For example, 
central controller 200 needs to obtain permission from a 
requestor before releasing his requestor data to a party. 

Returning to FIG. 5, central controller 200 can receive an 
authentication request to verify the authenticity of the origin, 
authorship, and/or integrity of party data or requestor data 
(step 520). Upon receiving this request, central controller 
200 verifies the data and transmits a verification status to the 
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party or requestor requesting data verification (step 520). 
Step 520 is described in greater detail in connection with 
FIG. 7. Central controller 200 receives a verification request 
from a requestor for verification of party data (step 700). As 

5 described above, this verification may include verifying the 
authenticity of any one of the origin, authorship, and integ- 
rity of the party data stored in databases 255. 

In response, central controller 200 transmits a verification 
status request to a verification authority to verify the party 

10 data (step 710). For instance, in the employment services 
example, the party data to be verified may include a uni- 
versity from which a candidate received an advanced degree. 
In that case, central controller 200 could transmit a verifi- 
cation status request to the candidate's purported educa- 

15 tional institution to verify that the candidate did, in fact, 
receive an advanced degree from that institution. 

When central controller 200 receives a response to its 
request indicating the verification status of the party data, 
central controller 200 stores the verification status in veri- 

20 fication database 270 (step 720), and transmits that verifi- 
cation status to the reqi^estor at requestor terminal 400 (step 
730). 

The method shown in FIG, 7 could be adapted to verify 
requestor data. In that case, central controller 200 receives a 

25 request from a party to verify requestor data and transmits a 
request to a verification authority. When central controller 
200 receives the verification status from the verification 
authority, it transmits the verification status to the party. 
Returning to FIG. 5, central controller 200 can establish 

30 an anonymous communications channel between a party and 
requestor (step 530). In this way, the party and the requestor 
can reveal or request information to and from each other. As 
described above, the communications channel can be real- 
time or non-real-time. FIG. 8 shows a flow diagram illus- 

35 traling one embodiment of a method for opening a commu- 
nications channel between party terminal 300 and requestor 
terminal 400 and FIG. 9 shows a flow diagram illustrating 
one embodiment of a method for managing the communi- 
cation between party terminal 300 and requestor terminal 

40 400. After receiving a communications channel request from 
a requestor to open a communications charmel with a party 
(step 800), central controller 200 transmits a communication 
request to the party at party terminal 300 (step 810). 
Preferably, the communication request asks the party 

45 whether it agrees to engage in a real-time or non-real-time 
communication with the requestor. 

If central controller 200 receives a response indicating 
that the party does not agree to engage in communication 
with the requestor (step 820), then central controller 200 

50 does not open the communications channel and the trans- 
action ends (step 830). If central controller 200 receives a 
response indicating that the party agrees to the request (step 
820), central controller 200 opens a communications chan- 
nel between party terminal 300 and requestor terminal 400 

55 (step 840). The communications channel can be set up as 
either a real-time or non-real-time connection including an 
audio system (i.e., a telephone system), an electronic mes- 
saging system, and a video communication system. In one 
embodiment, the communications channel includes a modi- 

60 fication processor for modifying voice and/or video. 

After opening the communications channel, central con- 
troller 200 debits the requestor's bilhng account stored in 
database 275 and transmits a bill to the requestor (step 850). 
Central controller 200 could also collect payment from the 

65 requestor using other payment methods including: on-file 
credit card, periodic statement billing, account debit, and 
digital cash. Further, in one embodiment, central controller 



07/29/2003, EAST Version: 1.04.0000 



5,884,270 



19 



20 



200 transmits payments to parties for party activities indud- 
ing: allowing central controller 200 to maintain party data in 
party data database 255, communicating with requestors, 
and releasing party data. 

FIG. 9 illustrates a flow diagram of the method of step 530 
for establishing a communications channel, in accordance 
with one embodiment of the invention. Central controller 
200 receives a message from a requestor addressed to a 
particular party by pseudonym (step 900). Central controller 
200 processes the message to remove any information that 
would reveal the identity of the requestor (step 910) in order 
to maintain the requestor's anonymity. Central controller 
200 transmits the processed message to the party at party 
terminal 300 (step 920). Central controller 200 receives a 
response to the message from the party, removes any infor- 
mation that would reveal the identity of the party (step 940), 
and transmits the processed response to the requestor (step 
950). 

Removing identity information may also include the use 
of voice and/or video modification processors in step 910 
and 940. Steps 900-950 are repeated to allow multiple 
messages to pass between the party and the requestor, while 
maintaining the anonymity of the party and requestor. In one 
embodiment, central controller 200 debits the requestor 
billing account according to the usage of the communica- 
tions channel between the party and the requestor (step not 
shown). Central controller 200 can measure usage of the 
communications channel using one of several methods, 
including: number of messages exchanged, time that central 
controller 200 maintains the communications channel, the 
requestor's status (i.e., premium customers pay less), and 
geographic location of party terminal 300 and/or requestor 
terminal 400. 

Central controller 200 collects payment for certain trans- 
actions performed. In accordance with one embodiment of 
the invention, central controller 200 transmits a btU to the 
requestor at requestor terminal 400 for each transaction and 
debits the requestors account (step 540), which is stored in 
database 275 of central controller 200. In alternative 
embodiments, the payment scheme can be modified or 
varied to charge either the requestor or the party or both for 
various transactions executed by system 100, and particu- 
larly central controller 200. In a further embodiment, the 
payment scheme involves paying the party for submitting 
information to central controller 200, opening a communi- 
cations channel, and/or releasing party data to a requestor. In 
one embodiment of the system, a parly is payed each time 
he authorizes the release of his parly data to a requestor. 
Central controller 200 will monitor the transactions to 
ensure that parties do not release information to the same 
requestor more than once in a given period of time. 

As stated earlier, maintaining the anonymity of the party 
and requestor can be important to their communications. For 
example, an employer may not want its competitors to know 
that it is looking to expand its staff because it may give them 
an advantage. An attacker may attempt to examine the 
message trafi&c coming in and out of central controller 200 
to expose the identity of a user of the system. A way to 
prevent this type of attack is to use an anonymous mix 
protocol during communication between a party or requestor 
and central controller 200. 

An anonymous mix uses a protocol to make it very 
difiBcult for anyone to trace the path of a message which 
passes through the mix. The anonymous mix takes outgoing 
messages from central controller 200 and randomly varies 
both the length of the message as well as the timing of its 
delivery. An incoming message of two hundred kilobytes, 



15 



20 



25 



30 



35 



40 



55 



65 



for example, might be expanded to three hundred kilobytes 
by adding random characters at the end. An attacker would 
thus be unable to correlate (by length of message) the 
incoming requestor query with requests to release party data 
sent to the various parties. By adding a random time delay 
in the processing of incoming requests, central controller 
200 also prevents an attacker from correlating (based on 
time) incoming requests with outgoing requests. An example 
of the anonymous protocol employed in the present inven- 
tion is set forth below. 
Notation and Conventions for this protocol: 

a. ^KEpj^^X) represents the public-key encryption of X 
imder public key PK(j. 

b. SIGN^jy(X) represents the digital signature of X under 
private key SKjj. 

c. E^o}(X) represents the symmetric encryption of X 
under key Kq. 

d. PK^/ represents the public key of user U. 
c. SKjy represents the private key of user U. 

f. Dj^ represents the identification number of user U. 

g. X,Y represents the concatenation of X with Y. 
Keys used in this protocol: 

a. PKjv^ is the anonymous mix public key. 

b. ID^ is Bob's ID. 

c. PK^ is Bob's public key. 

d. SKg is Bob's private key. 

When Alice sends Bob a message through anonymous 
mix, the following steps could take place: 

a. Alice wishes to send message T to Bob anonymously. 
She first forms: 

Ko=a random session key. 
Po=an all-zero string of some random length. 
Xo=PKEpR3/Ko) . 
Mo=Xo,E^(ID^,Po,T). 

Alice then sends Mq to the anonymous mix 180. Note 
that Alice may also have encrypted and digitally 
signed the message she's sending to Bob. This has no 
bearing at all on how the anonymous mix processes 
it. Po disguises the size of the message, making it 
difiScult, or virtually impossible, to correlate incom- 
ing messages with outgoing messages. 

b. The anonymous mix receives Mq. Using X^, anony- 
mous mix decodes the random session key Kq using 
anonymous mix private key SK^^ and then using Kq, 
ID^, T and are decrypted. The anonymous mix looks 
up Bob's public key from ID^, and then forms: 
K^=a random session key. 

P^san all-zero string of some random length. 

X^«PKE^j^^(Kj). 

M,=X,E^,(P„T) 

Anonymous mix waits some random amount of time 
before sending to Bob. During this time, it is 
processing many other messages, both sending and 
receiving them, 

c. Bob receives M^. He decrypts it using his private key, 
SK^ and recovers T He then does whatever he needs to 
with T. 

In order to make messages that pass through an interme- 
diary anonymous mix anonymous, a large volume of mes- 
sages coming in and out are reviewed. A random delay 
involved in forwarding those messages may also be 
required. Otherwise, it is possible for an opponent to watch 
messages going into and coming out of anonymous mix, 
using this information to determine the source and destina- 
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tioD of each message. Similarly, messages must be encrypted 
to the anonymous mix, so that the messages can be 
decrypted and re-encrypted with a different key. Also, mes- 
sages may need to be broken into many pieces or padded 
with large blocks of data, to avoid having message lengths 
give away information. Anonymous mix either knows 
everyone's public keys or their public keys are sent along 
with their identities. Every user is assumed to know anony- 
mous mix's public keys. The anonymous mix, used in 
combination with encryption and digital signatures dis- 
cussed earher, provides a high level of anonymity for both 
parties and requestors. 

Anonymity may also serve to prevent a requestor and 
party from contacting each other outside the system in order 
to ensure that payment is received for bringing the two 
together. In this embodiment, central controller 200 forces 
anonymity by bUnding one or both parties. The requestor, 
for example, may not see the name of the party until the 
requestor's account has been debited. 

FIGS. 8 and 9 illustrate a method in which a communi- 
cations channel between a party and requestor is established 
and managed by system 100 without either the party or the 
requestor learning the other's identity. While FIGS. 8 and 9 
illustrate methods in which central controller 200 establishes 
the communications channel at a requestor's request, in 
alternative embodiments, a communications channel can be 
established at a party's request. In that case, central con- 
troller 200 receives a request for a communications channel 
from party terminal 300, transmits the request to requestor 
terminal 400, and establishes a communications channel in 
accordance with the requestor's response. 

White the inyeotio n^s embo died and described in jx )n- 
ji ection with svstem^lOO, can~De applied to the employm ent 
search process, the invention can also be applied to a_v aDety 
of other areas involving anonymous communications. Fo r 
in stance, svstem 100 can be used in conae ctinn with match- 
making (i.e., providing dating services). People, or "parties /' 
interested in datinp; can enter personal da^ ta . or "partv data ." 
about themselves at party terminals ^Q. For each party , the 
p arty data may include the party's identity, the party's vit al 
s taristics^ the party's backgrouna.'andibe p art y^s interes ts. 
Central controller 200 and party terminals 300 ife Cfiive-and 
tra nsmit the party data in the manner described above. _ 

people, or "requestors." who would like to find parties 
w hose persopal data s atis fies their interests or tastes^ an 
enter a search request at reque stor termmai 400^ In one 
embodiment, requestors enter data, or "requestor data/' 
about themselves at request terminal 400, which encrypts 
and transmits the requestor data to central controller 200. In 
addition, each requestor enters, at request terminal 400, a 
search request specifying attributes about people that the 
requestor would like to date. For instance, the search request 
may specify that the requestor is interested in identifying 
men that are at least 6' tall and are college-educated. Request 
terminal 400 encrypts the search request and transmits the 
encrypted search request to central controller 200 for 
processing, as described above. 

In response to the search request, central controller 200 
preferably transmits to requestor terminal 400 the number of 
people found to satisfy the criteria in the request, as 
described above in connection with FIG. 6 A. In the example 
given above, central controller 200 would transmit to 
requestor terminal 400 the number of people who indicated 
that they are men, 6' tall, and college-educated, as revealed 
by party data database 255. Central controller 200 releases 
party data and requestor data to the requestor and parties, 
respectively, in the manner described above in connection 
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with FIG. 6B. Central controller 200 can verify data, as 
described in connection with FIG. 7, and open a communi- 
cations channel between a requestor and a party, as 
described in connection with FIGS. 8 and 9. When central 
controller 200 opens the communications channel, the 
requestor and the party can exchange adequate information 
about themselves to decide whether to agree to a date 
without subjecting themselves to any risk if either should 
decide not to agree to the date. 

The employment search and dating services examples 
demonstrate how the invention can: allow a requestor to 
search for parties meeting certain criteria, allow parties to 
control the release of information about themselves, and 
provide a communications channel between a requestor and 
the parties while maintaining the anonymity of the parties 
and the requestor from each other. The mvention, however, 
is not limited to those types of applications. Other applica- 
tions include finding and interviewing consultants or 
freelancers for a specific project, auditioning actors and 
actresses, seeking a merger partner, and engaging in various 
commerce-based applications in which controlled anonym- 
ity by any party would be benefi.cial. 

The invention can be used in applications where the 
system establishes a communicatioos channel between par- 
ties and authenticates information about the parties, while 
maintaining the anonymity of at least one of the parties. In 
one embodiment, system 100, as described above, could be 
used for such applications. This embodiment allows two 
parties to communicate while each party is ensured that the 
information being communicated is valid. For example, in 
the case of a "whistle-blowing" application (outlined below) 
an employer can be certain that the information he receives 
is from an employee within his organization. The methods 
illustrated by the flow diagrams of FIGS. 5-9 could be 
readily adapted for these applications. 

By way of example, system 100 could be used as a 
"whistle-blowing" system to allow employees of a company 
to anonymously report legal and policy violations without 
risking retribution by the company's management. The 
employee reporting a violation would preferably enter, into 
party terminal 300, data about the violation and data that can 
be independently verified as originating from the employee 
claiming the violation. The employee is referred to hereafter 
as the "party" and the data entered into party terminal 300 
is referred to hereafter as the "party data." In one 
embodiment, the party data may include an employee iden- 
tification number uniquely identifying each employee of the 
company. Party terminal 300 encrypts and transmits the 
party data to central controller 200, preferably in the manner 
described above. 

A company representative, referred to as the "requestor," 
would use requestor terminal 400 to access the party data 
stored jn central controller 200. After accessing the party 
data about the violation, the requestor could submit a request 
at requestor terminal 400 to have some or all of the party 
data authenticated. For example, central controller 200 could 
verify that the party is, in fact, an employee of the company 
by comparing an employee identification number contained 
in the party data with a list of active company employee 
identification numbers. If the number matches, central con- 
troller 200 would transmit a response to requestor terminal 
400 confirming that the party is an active employee of the 
company. 

The requestor, or the party, could enter a request into 
requestor terminal 400, or party terminal 300, for central 
controller 200 to open a communications channel with the 
party, or the requestor. Central controller 200 would open a 
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communications channel, as described above in connection 
with FIGS. 8 and 9, to allow the party and the requestor to 
communicate, while maintaining the party's anonymity. 
This would allow the employer to question the employee 
about details relating to the incident in question, without the 5 
employee revealing his identity. 

In another example, system 100 could be used as a system 
to allow parties to remain anonymous while negotiating an 
agreement. For instance, criminals, or rule offenders, anony- 
mously offer to turn themselves in, while negotiating favor- 
able treatment. In this case, the criminals, or rule offenders, 
would represent the "parties" and law enforcement, or rule 
enforcers, would represent the "requestors." In a preferred 
embodiment, a party would enter, at party terminal 300, 
information ("party data") about his violation and data that 
can be independently verified as originating from the party 
claiming the violation. The party data can include the party's 
identity, which is preferably only used by system 100 for 
verification purposes. Party terminal 300 would encrypt and 
transmit the party data to central controller 200, in the 
manner described above. A requestor would use requestor 20 
terminal 400 to access the party data stored in central 
controller 200. 

The requestor could enter a request for authentication of 
the party data into requestor terminal 300, which would 
transmit the request to central controller 200. Central con- 25 
troUcr 200 would verify some or all of the party data, as 
described above, and transmit a verification status message 
to requestor terminal 400. Upon request from either party 
terminal 300 or requestor terminal 400, central controller 
can establish an anonymous communications channel with 30 
the other terminal, provided that the party and the requestor 
agree to engage in the communications channel. As 
described above, this communications channel can be real- 
time or non -real- time. 

Under the "plea bargaining" example, the invention 35 
aEows the requestor and the party to negotiate the terms of 
the party's sentence or punishment for committing the 
violation before the party reveals his identity. If negotiations 
fail, the party does not subject himself to any risk that the 
requestor will leam his identity simply because he initiated 40 
commimication. The requestor, of course, can use whatever 
information the party revealed about himself during the 
course of the negotiation to leam the identity of the party. 

Besides the whistle-blowing and plea bargaining 
examples, the invention also applies to other applications, 45 
such as authenticated phone-based tip lines and licensing 
negotiations where a Ucensee does not want to reveal the 
size of his company for fear of being charged more by the 
licensor. 

Conclusion 

It will be apparent to those skilled in the art that various 
modifications and variations can be made in the system and 
method of the present invention without departing from the 
spirit or scope of the invention. The present invention cover 55 
the modifications and variations of this invention provided 
they come within the scope of the appended claims and their 
equivalents. 

What is claimed is: 

1. A method for operating a computer system to facilitate 
an exchange of identities between two anonymous parties, 
comprising the steps of: 

receiving from a first party first data including an identity 

of said first party; 
receiving from said first party at least two first-party rules 65 
for releasing said first data including a rule for releasing 
said identity of said first party; 
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receiving from a second party a search request comprising 

at least one search criterion; 
receiving fi*om said second party second data including an 

identity of said second party; 
receiving from said second party at least two second-party 
rules for releasing said second party data including a 
rule for releasing said identity of said second party; 
processing said search request to determine if said first 

data satisfies said search criterion; and 
if said first data satisfies said search criterion, then 
exchanging said first and second data, except said 
identities of said first and second parties, between 
said first and second parties in accordance with said 
first-party and second-party rules, 
after said exchanging step, upon satisfying said first- 
party mle for releasing said identity of said first 
party, transmitting said identity of said first party to 
said second party, and 
after said exchanging step, upon satisfying said second- 
party rule for releasing said identity of said second 
party, transmitting said identity of said second party 
to said first party. 

2. A method in accordance with claim 1 wherein said step 
of receiving from a first party at least two first-party rules 
includes receiving at least one first-party rule before receiv- 
ing said search request and storing said at least one first- 
party rule. 

3. A method in accordance with claim 2 wherein said step 
of receiving from a first party at least two first-party rules 
includes requesting at least one first-party rule from said first 
party after receiving said search request. 

4. A method in accordance with claim 3 wherein said at 
least one first-party rule received after said search request 
includes an authorization to release said identity of said first 
party. 

5. A method in accordance with claim 1 wherein said step 
of receiving from said second party at least two second -party 
rules includes receiving at least one second-party rule before 
receiving said search request and storing said at least one 
second-party mle. 

6. A method in accordance with claim 5 wherein said step 
of receiving from a second party at least two second -party 
mles includes requesting at least one second -party rule from 
said second party after processing said search request. 

7. A method in accordance with claim 6 wherein said at 
least one second -party rule received after processing said 
search request includes an authorization to release said 
identity of said second party. 

8. A method in accordance with claim 1 and further 
including, subsequent to said step of exchanging said first 
and second data, the step of receiving a request to establish 
a communications channel between said first and second 
parties prior to releasing the identity of at least one of said 
first and second parties. 

9. A method in accordance with claim 8 and further 
including the step of establishing said communications 
channel between said first and second parties. 

10. A method in accordance with claim 1 wherein at least 
one of said first-party rules is conditional on the content of 
said second data. 

11. A method in accordance with claim 1 wherein at least 
one of said second-party rules is conditional on the content 
of said first data, 

12. A system for facihtating an exchange of identities 
between two anonymous parties, comprising: 

means for receiving from a first party first data including 
an identity of said first party; 
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means for receiving from said first party at least two 
first-party rules for releasing said first data including a 
rule for releasing said identity of said first party; 

means for receiving from a second party a search request 
comprising at least one search criterion; 

means for receiving from said second party second data 
including an identity of said second party; 

means for receiving from said second party at least two 
second -party rules for releasing said second party data 
including a rule for releasing said identity of said 
second party; 

means for processing said search request to determine if 

said first data satisfies said search criterion; and 
means for, if said first data satisfies said search criterion, 

exchanging said first and second data, except said 
identities of said first and second parties, between 
said first and second parties in accordance with said 
first -party and second-party rules, 

after said exchanging, upon satisfying said first-party 
rule for releasing said identity of said first party, 
transmitting said identity of said first party to said 
second party, and 

after said exchanging, upon satisfying said second- 
party rule for releasing said identity of said second 
party, transmitting said identity of said second party 
to said first party. 

13. A system in accordance with claim 12 wherein said 
means for receiving from a first party at least two first-party 
rules includes means for receiving at least one first-party 
rule before receiving said search request and storing said at 
least one first -party rule. 

14. A system in accordance with claim 13 wherein said 
means for receiving from a first party at least two first-party 
rules includes means for requesting at least one first-party 
rule from said first party after receiving said search request. 

15. A system in accordance with claim 14 wherein said at 
least one first-party rule received after said search request 
includes an authorization to release said identity of said first 
party. 

16. A system in accordance with claim 12 wherein said 
means for receiving fi-om said second party at least two 
second -party rules includes means for receiving at least one 
second -party rule before receiving said search request and 
storing said at least one second-party rule. 

17. A system in accordance with claim 16 wherein said 
means for receiving from a second party at least two 
second-party rules includes requesting at least one second- 
party rule from said second party after processing said 
search request. 

18. A system in accordance with claim 17 wherein said at 
least one second-party rule received after processing said 
search request includes an authorization to release said 
identity of said second party. 

19. A system in accordance with claim 12 and further 
including, subsequent to said exchanging said first and 
second data, means for receiving a request to establish a 
communications channel between said first and second 
parties prior to releasing the identity of at least one of said 
first and second parties. 

20. A system in accordance with claim 19 and further 
including means for establishing said commimications chan- 
nel between said first and second parties. 

21. A system in accordance with claim 12 wherein at least 
one of said first-party rules is conditional on the content of 
said second data. 

22. A system in accordance with claim 12 wherein at least 
one of said second -party rules is conditional on the content 
of said first data. 
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23. A system for facilitating an exchange of identities 
between two anonymous parties, comprising: 

a processor; and 
^ a memory connected to said processor and storing a 

program for controlling the operation of said processor; 
said processor operative with said program in said 

memory to: 

receive from a first party and store in said memory first 
10 data including an identity of said first party; 

receive from said first party and store in said memory 
at least two first-party rules for releasing said first 
data including a rule for releasing said identity of 
said first party; 

15 receive from a second party and store in said memory 
a search request comprising at least one search 
criterion; 

receive from said second party and store in said 
memory second data including an identity of said 
second party; 

receive from said second party and store in said 
memory at least two second-party rules for releasing 
said second party data including a rule for releasing 
25 said identity of said second party; 

process said search request against said first data in said 
memory to determine if said first data satisfies said 
search criterion; and 
if said first data satisfies said search criterion, then 
30 exchange said first and second data, except said 

identities, between said first and second parties in 
accordance with said first-party and second-party 
rules, 

after said exchanging operation, upon satisfying said 
35 first-party rule for releasing said identity of said 

first party, transmit said identity of said first party 
to said second party, and 
after said exchanging operation, upon satisfying said 
second-party nde for releasing said identity of said 
40 second party, transmit said identity of said second 

party to said first party. 

24. A system in accordance with claim 23 wherein said 
step of receiving from a first party at least two first-party 
rules includes receiving at least one first-parly rule before 

45 receiving said search request and storing said at least one 
first-party mle. 

25. A system in accordance with claim 24 wherein said 
step of receiving from a first party at least two first-party 
rules includes requesting at least one first -party rule from 

50 said first party after receiving said search request. 

26. A system in accordance with claim 25 wherein said at 
least one first-party rule received after said search request 
includes an authorization to release said identity of said first 
party. 

55 27. A system in accordance with claim 23 wherein said 
step of receiving from said second party at least two second- 
party rules includes receiving at least one second-party rule 
before receiving said search request and storing said at least 
one second-party rule. 

60 28. A system in accordance with claim 27 wherein said 
step of receiving from a second party at least two second- 
party rules includes requesting at least one secx)nd-party rule 
from said second party after processing said search request. 
29. A system in accordance with daim 28 wherein said at 

65 least one second-party rule received after processing said 
search request includes an authorization to release said 
identity of said second party. 
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30, A system in accordance with claim 23 and further 
including, subsequent to said step of exchanging said first 
and second data, the step of receiving a request to establish 
a communications channel between said first and second 
parties prior to releasing the identity of at least one of said 5 
first and second parties. 

31. A system in accordance with claim 30 and further * 
including the step of establishing said communications 
channel between said first and second parties. 
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32. A system in accordance with claim 23 wherein at least 
one of said first-party rules is conditional on the content of 
said second data. 

33. A system in accordance with claim 23 wherein at least 
one of said second-party rules is conditional on the content 
of said first data. 

)|i « 4c * >|t 
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